Thanks for tackling this — the unified Result<T, E> type and Error-typed error field will pay off in telemetry and instanceof checks.

The bulk of this is a clean mechanical migration, but several of the converted return sites silently dropped fields that used to be part of the success/failure shape (log paths, console URLs, session IDs, exec payloads, warnings). Because many of these are exposed through --json, they're effectively public CLI output contracts. I've left inline comments on the spots that look like real behavior regressions. Once those are addressed (or intentionally accepted), this should be good to go.

A couple of smaller items not worth individual comments:

• src/cli/operations/traces/insights-query.ts around L80: err.message ? new Error(err.message) : new Error(String(error)) — this could just be toError(error) for consistency with the rest of the migration.
• src/cli/commands/deploy/actions.ts:664: if (!tsResult.success && tsResult.error) — with the new discriminated union, tsResult.error is guaranteed present whenever !tsResult.success, so the second clause is redundant. Just if (!tsResult.success) reads cleaner.

Nice work on the unified Result<T, E> refactor — the typed error field is a clear improvement, and on the latest commit the behavioral regressions earlier reviewers flagged (exec-mode payload, sessionId on failures, warnings passthrough, consoleUrl on traces failures, NoProjectError typing) all appear to be addressed.

One systemic issue to flag before approving: there's a cluster of catch blocks that still strip the original error's type by doing new Error(err.message) (or an equivalent string round-trip). This directly undermines the PR's stated goal — downstream instanceof AccessDeniedError / instanceof DependencyCheckError / etc. checks, error-name matching in telemetry, and cause chains all break at these seams, because every one of them reconstructs a plain Error and forgets the original.

toError(err) in src/cli/errors.ts already exists for exactly this purpose; every one of these sites should use it (or, if a wrapping message is really wanted, pass { cause: err } so the original is still reachable via error.cause and instanceof still works on the cause). Inline comments below point out each occurrence I found.

Reviewed the latest revision (fc93cd7).

I walked through the diff and cross-checked against the existing review threads. The behavior regressions flagged earlier (status --json missing fields, invoke --exec --json payload, sessionId on invoke failures, traces get consoleUrl, dependency-check warnings, deploy log path on stderr vs stdout, NoProjectError typing in AgentPrimitive) have all been fixed in this revision. The new Error(err.message) type-stripping cluster (primitives remove(), remove-gateway-target, run-batch-evaluation, run-recommendation, handleImport, resource-import, import-gateway, MCP/A2A/AGUI failure paths in invoke/action.ts, insights-query.ts) has also been converted to toError(err) or wrapped with { cause: err }, so instanceof / error.name / cause-chain inspection now survives the seams. Ran grep for the pre-existing patterns to double-check — none remain in files touched by this PR.

No new serious issues found beyond what was already flagged. LGTM — approving.